
Calhoun: The NPS Institutional Archive 
DSpace Repository 


Theses and Dissertations 


1. Thesis and Dissertation Collection, all items 


1992-03 

An experimental investigation of the effects of 
software size increase on software project 
management behavior 

Baker, Diana L. 

Monterey, California. Naval Postgraduate School 


http://hdl.handle.net/10945/38537 
Downloaded from NPS Archive: Calhoun 



DUDLEY 

KNOX 

LIBRARY 


Calhoun is a project of the Dudley Knox Library at NPS, furthering the precepts and 
goals of open government and government transparency. AIJ information contained 
herein has been approved for release by the NPS Public Affairs Officer. 

Dudley Knox Library / Naval Postgraduate School 
411 Dyer Road / 1 University Circle 
Monterey, California USA 93943 


htt p://w w w. n ps.e-d u/l ib ra ry 


AD-A248 362 




NAVAL POSTGRADUATE SCHOOL 

Monterey, California 


I 




DT1C 

ELECTE 
APR OT 1992 


0 




THESIS 


AN EXPERIMENTAL INVESTIGATION 
OF THE EFFECTS OF SOFTWARE SIZE INCREASE 
ON SOFTWARE PROJECT MANAGEMENT BEHAVIOR 

by 

Diana L. Baker 
March, 1992 

Thesis Advisor: Tarek K. Abdel-Hamid 


Approved for public release; distribution is unlimited 


92-08898 



92 4 06 169 






UNCLASSIFIED 


SECURITY CLASSIFICATION OF THIS PAGE 


REPORT DOCUMENTATION PAGE 


la REPORT SECURITY CLASSIFICATION 
UNCLASSIFIED 


2a SECURITY CLASSIFICATION AUTHORITY 


2b DECLASSIFICATION/DOWNGRADING SCHEDULE 



1b RESTRICTIVE MARKINGS 


3 DISTRIBUTION/AVAILABILITY OF REPORT 
Approved lor public release; distribution is unlimited. 


4 PERFORMING ORGANIZATION REPORT NUMBER(S) 


5 MONITORING ORGANIZATION REPORT NUMBE R(S) 


6 a NAME OF PERFORMING ORGANIZATION 
Naval Postgraduate School 


6 c ADDRESS [City, State, and ZIP Code) 
Monterey, CA 93943-5000 


6 b OFFICE SYMBOL 
(If applicable) 

55 


7a NAME OF MONITORING ORGANIZATION 
Naval Postgraduate School 


7b ADDRESS (City, State, and ZIP Code) 
Monterey, ('A 93943-5000 


8 a NAME OF FUNDING/SPONSORING 
ORGANIZATION 


8 b OFFICE SYMBOL 
(If applicable) 


9 PROCUREMENT INSTRUMENT IDENTIFICATION NUMBER 


8 c ADDRESS (City, State, and ZIP Code) 


10 SOURCE OF FUNDING NUMBERS 


Program fc lement No 



Worn onii At\e&*a>or> 


11 TITLE (Include Security Classification) 

An Experimental Investigation oflhe Effects of Software Size Increase on Software Project Management Behavior 


12 PERSONAL AUTHOR(S) Baker, Diana L. 


13a TYPE OF REPORT 
Master's Thesis 


13b TIME COVERED 
Fiom To 


14 DATE OF REPORT (year, month, day) 15 PAGE COUNT 
1992, March 74 


16 SUPPLEMENTARY NOTATION 

The views expressed in this thesis are those of the author and do not reflect the official policy or position of the Department of Delense or the U.S 
Government. 


17 COSATI CODES _ 18 SUBJECT TERMS (continue on reverse if necessary and identify by block number ) 

FIELD i GROUP I SUBGROUP Software. Software Project Management, System Dynamics, Visibility, Game Theory, 

Simulation 


19 ABSTRACT (continue on reverse if necessary and identify by block numbe r) 

Increasing demand (or software and increasing shortfalls of programmers have focused efforts to improve software project productivity on the 
role of the software project manager. The complex dynamics of software project development, and the 'visibility'of the project, affect decision 
making and performance to a large degree. Using the System Dynamics Model for software project management, these and other issues can be 
evaluated with low financial risk or outlays through simulation of software projects. 

This thesis investigates the effect of changing one uf the dynamics I i.e., size) on the behavior and performance oflhe project manager by using a 
simulation of an actual suftware project in u game environment. Analysis oflhe results indicates that increased visibility significantly improves 
project schedule. 


20 DISTRIBUTION/AVAILABILITY OF A 8 STRACT 

SAMI ASKlt'OKI 


UNClASSItltD'llNl IMinn 


22a NAME OF RESPONSIBLE INDIVIDUAL 
Professor Tarek K. Abdel Humid 


DD FORM 1473.84 MAR 


21 ABSTRACT SECURITY CLASSIFICATION 
UNCLASSIFIED 


22b TELEPHONE (Include Area code) 
(408)646 2686 


83 APR edition may be used until exhausted SECURITY CLASSIFICATION! 

All other editions are obsolete UNCLASSIFIED 


22c OFFICE SYMBOL 
AS All 


1 















































Approved for public release; distribution is unlimited. 


AN EXPERIMENTAL INVESTIGATION 
OF THE EFFECTS OF SOFTWARE SIZE INCREASE 
ON SOFTWARE PROJECT MANAGEMENT BEHAVIOR 

by 

Diana L. Baker 
Major, United States Army 
B.A., Mount Holyoke College, 1978 

Submitted in partial fulfillment 
of the requirements for the degree of 

MASTER OF SCIENCE IN INFORMATION SYSTEMS 

from the 


NAVAL POSTGRADUATE SCHOOL 


Author: 


Approved by: 



11 







ABSTRACT 


Increasing demand for software and increasing shortfalls 
of programmers have focused efforts to improve software 
project productivity on the role of the software project 
manager. The complex dynamics of software project 
development, and the "visibility" of the project, affect 
decision making and performance to a large degree. Using the 
System Dynamics Model for software project management, these 
and other issues can be evaluated with low financial risk or 
outlays through simulation of software projects. 

This thesis investigates the effect of changing one of the 
dynamics (i.e., size) on the behavior and performance of the 
project manager by using a simulation of an actual software 
project in a game environment. Analysis of the results 
indicates that increased visibility significantly improves 
project schedule. 
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I. INTRODUCTION 


A. BACKGROUND 

Software project management is not only facing a serious 
backlog of projects that need to be maintained, created and 
designed, but also an increasing shortfall of trained 
programmers available to do the job. Recognizing the 
increased workload and the decreasing workforce, technological 
advances have assisted productivity, but show no signs of 
catching up with, let alone meeting demand. 

As usual, management of the process has come under 
increasing scrutiny as the last hope of the software project 
manager. Software project management is far more complex, 
however, than the management of a hardware or industrial 
project. The dynamics of resource management are far more 
complex, due to the continual shifts in work force, 
technological situation, supply and demand of supporting 
resources, requirements and/or specifications, etc. 

Two crucial elements of any project manager's resource 
allocation plan are people and time/cost. Faced with the 
realities of a competitive job market, tight schedules and a 
budget, the manager must consider not only those factors, but 
their possible effects on all other factors. Of significant 
interest, given the statistics on personnel availability and 
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project size growth, are projections of what is best for a 
manager to do in the face of schedule expectations and growth 
realities. 

DeMarco asserts that the "political" pressures affecting 
schedule and cost status reporting are more appropriately 
called sociological factors, because of the complex social 
dynamics involved [Ref. 1] . Because of this, the status 
reported and its interpretation often negatively affect the 
progress of the project. The concept of project "visibility," 
an accurate representation not only of the project's size but 
also of actual progress made, is cited in the literature 
(DeMarco, Abdel-Hamid) as being key to controlling and 
reducing project schedule and cost overruns [Ref. 2] [Ref. 3] . 

The "90% Syndrome" is a tendency in which Baber suggests 

Estimates of the fraction of work completed [increase] as 
originally planned until a level of 80-90% is reached. 
The programmer's individual estimates then increase only 
very slowly until the task is actually completed [Ref. 4] . 

According to Abdel-Hamid [Ref. 2], there is "ample evidence in 

the literature to indicate that this phenomenon is pervasive 

in software project management," and that it affects many of 

the other factors involved. How the project manager copes 

with this problem while managing resources to deal with 

changes in project size or complexity is of crucial importance 

to the success (being on time, within budget and meeting the 

user requirements) of a project. 
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B. PURPOSE OF RESEARCH 

The purpose of this thesis is to design, construct and 
execute an experiment involving the single project management 
environment, using the Systems Dynamic Model (SDM) gaming 
interface. The Systems Dynamic Model is a comprehensive model 
of the dynamics of software development, allowing simulation, 
testing and evaluation of different software project 
management environments. It allows one or several factors to 
be manipulated while holding all others constant, and offers 
a cost effective opportunity to study the dynamics of decision 
making in a dynamic environment. 

This experiment addresses the effect of project size 
change on project processes and performance. The concept of 
visibility has been discussed in terms of management 
situations, but has not been empirically tested in any project 
management domain in the literature dealing with change or 
project management. 

The gaming interface presents the subject managers with a 
standard interface to the model; they are required to make 
staffing level decisions and project cost estimates through 
the design and testing phases of a software develoment 
project. Their performance is measured by their final cost 
and completion date of the project. The SAS statistical 
software is then used to measure process and performance 
deviation significance; the effect of the manipulated 
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variables on the actions and performance of the subject 
managers. 

C. SCOPE OF RESEARCH 

The scope of this research includes the design, 
construction, preparation of software and documentation, and 
execution of the single project experiment to investigate the 
following hypotheses (stated in alternative form): 

1. Process Hypotheses 

la. Project managers presented with gradual change in 
project size will make different cost estimate decisions than 
project managers presented with an abrupt increase in size of 
the same magnitude. 

lb. Project managers presented with gradual change in 
project size will make different staffing decisions than 
project managers presented with an abrupt increase in size of 
the same magnitude. 

2. Performance Hypothesis 

Project managers presented with gradual change in 
project size will perform differently than project managers 
presented with an abrupt increase in size of the same 
magnitude. 

D. ASSUMPTIONS 

The students in this experiment were fifth-quarter (in a 
six-quarter curriculum) graduate students enrolled in the 
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Computer Systems Management curriculum at the Naval 
Postgraduate School. Although the students were not actual 
software project managers, the amount of education in software 
project management and related subjects provided thus far in 
the curriculum, coupled with general management experience in 
their careers to date lends credence to the assumption that 
the results of the experiment and the findings and conclusions 
would be representative of the industry. This assumption is 
further supported by the findings of William Remus [Ref. 5]. 

E. THESIS ORGANIZATION 

Chapter II is a description of the experiment design, to 
include software and documentation and preparation of the 
experiment itself and the description of a trial experiment, 
its lessons and the changes made to the experiment as a 
result. Chapter III describes in depth the methodology, 
sample population and conduct of the experiment. Chapter IV 
provides a validation and analysis of the experimental raw 
data. Chapter V summarizes the findings of the previous 
chapters and their implications, and provides recommendations 
for further research. 
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IX. PREPARING TEE GAMING INTERFACE 


A. EXPERIMENTAL DESIGN 

This experiment uses the Systems Dynamic Model to develop 
an experimental simulation of a software project; this allows 
the creation of a "game" not unlike a flight simulator, in 
that the player must pilot the project from point A to point 
B within given constraints and guidelines. The simulation 
mimics a software project from the start of its Design Phase 
until the end of the Testing Phase. 

The player, or subject, plays the role of manager of a 
software project; when he/she initiates the 'game" program, 
the program presents an introductory screen (Figure 2-1) that 
reiterates the decisions (staffing levels and project cost 
estimates) that t;.e player is expected to make as manager 
based on periodic status reports. It then prompts the user to 
initiate the first simulated time interval of 40 days (two 
months) and performs the simulation. 

Once the simulation of an interval is completed, the game 
program displays a revised status report of the project based 
on the 40-day interval, to include an updated size estimate 
and an estimate of the percentage of development and/or 
testing which has been completed (Figure 2-2). Based on this 
information, the user may input a new desired staffing level. 
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Important Points to Remember !!!!!!!!! 

************************************** 

- You are not allowed to discuss this exercise with 
anyone other than a lab attendant. Please refrain from 
discussing this with other class members until they 
have completed the project. 

- The system will run through the first simulation 
period (2 months) and provide you with a status report. 
At the end of each reporting period, you will have an 
opportunity to revise the estimated total project cost 
(in man days), and to revise your desired staff level. 

-Make your changes to the cost estimate and the 
desired staffing level both on the documentation sheet 
provided and on the screen. 

A LAB ATTENDANT MUST VERIFY YOUR FINAL RESULTS! 

- GOOD LUCK! Press <ENTER> to continue. 


FIGURE 2-1 Introductory Screen 


or accept the previous level (which is the default), and input 
a new estimated project cost (in man days) or accept the 
previous value (default). 

Once these values are input or accepted, and entered on a 
data documentation sheet provided to each player, the game 
prompts the player to continue to the simulation of the next 
interval. The game continues until the project is complete in 
terms of development and testing, and indicates the time 
(schedule) and cost (man days) of completion. Players are 
under no staffing level or project cost estimate constraints, 
although they are reminded before the game begins of the need 
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PROJECT STATUS REPORT 


ELAPSED TIME =========> 40 Days 

ESTIMATES MADE AT THE START OF THE PROJECT 
Project Size 396 Tasks 

Project Cost in Man Days i,lll Man Days 

Project Duration 320 Days 

PROJECT STATUS at Time = = = = = = = => 40 Days 

Updated Estimate of Total Project Size 396.50 Tasks 
Development(Design & Code) 

Reported Complete 12.84 Percent 

% Testing Reported Complete 0.00 Percent 

Updated Estimate of Total Man Days 1,111 Man Days 
Total Man Days Expended to date 164.17 Man Days 

Updated Est. of Project Duration 
(start-end) 229 Days 

Current Staff Size 4.5 Fulltime Staff 


PRESS <ENTER> TO RETURN TO MENU 


FIGURE 2-2 PROJECT STATUS REPORT 

to remain as close as possible to the budgeted schedule and 
cost. 

The actual experiment consisted of two different SDM 
models, both of which were based on a NASA experiment which 
has been used as a basis for other research efforts. By using 
real data from real projects, we can measure and compare the 
results of the experiment to a known baseline based on 
reality. Subjects were divided randomly into two groups. 
Group GRADUAL was directed to run the 'EXP1' program, in which 
they were presented with a simulated software project that 
grew gradually in size from 320 tasks (a task being equal to 
approximately 50 lines of code) to 610 tasks by day 100. 








Group ABRUPT players ran the 'EXP2' program, in which they 
managed a project which remained the same size (320 tasks) 
through the 100th day of the simulation; after the Day 80 
status report, the players received a message on the screen 
alerting them that due to increased requirements, the project 
size had just increased to 610 tasks. After this point, the 
estimated size of the project remained the same (at 610 
tasks). 

The motivation in each case was the same; the subjects 
were told that their participation in the experiment would be 
rewarded with extra credit points in the Software Engineering 
course they were taking. Although the number of points they 
would receive was not linked to their performance, they were 
told that their objective was to complete the project as close 
as possible to the original estimates of schedule and cost. 
These original estimates appeared at the top of the status 
report for each time interval. 

Two days prior to the conduct of the actual experiment, 
each subject received an initial 45-minute briefing regarding 
their objectives in the experiment, possible ways of 
interpreting the status reports, and advice regarding the 
reliability of estimates in software projects. Prior to the 
actual experiment, each subject performed a trial run 
simulation called TEST on an individual basis; the design and 
documentation is discussed later in this chapter. The purpose 
of these training and orientation sessions was to eliminate 
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discomfort or unfamiliarity with the interface and the game. 
The TEST simulation revealed no increase in size of the 
project, nor did it allow the simulation to run beyond the 80- 
day interval, in order to preclude advance knowledge or bias 
of the actual experiment. Each subject thus played the TEST 
simulation for two 40-day periods, then exited the TEST 
program and initiated the EXP1 or EXP2 program, depending on 
their group. 

B. THE SOFTWARE 

In order to construct the experiment, the gaming interface 
of the SDM model had to be tailored to the experimental 
design, and explanatory documentation developed to outline the 
background, instructions, tasks, rules and other 
considerations to the subjects. 

The interface includes the Dynamo simulation files and 
Dynex files, which allow the model designer to interface with 
the simulation language and construct the experimental design. 
Once complete, the interface is transparent to the 
experimental subject, who simply starts and plays the 'game' 
without knowledge of the workings of the simulation itself. 
Further, the interface must include the means for capturing 
the raw data obtained from each subject's decisions for 
further analysis. 

The language interface that the designer of the experiment 
uses is called Dynex. Through the use of any text editor, the 
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Dynex (or DNX) file is created to perform the following 
functions: display information to the player identifying what 
the player needs to do, capture the variables input by the 
player required for the simulation, and provide a format for 
the output (status report) screens. Copies of the TEST, EXPl 
and EXP2 Dynex files and their associated screens are in 
Appendices A, B, and C, respectively. 

The interface is controlled by a batch (BAT) file of the 
same name, which invokes the interface, provides instructions 
after each simulation is completed, invokes the display of the 
status report or the initiation of the next set of player 
inputs and provides overall 'play-by-play' control of the 
game's events. Copies of the TEST, EXPl, and EXP2 batch 
control files are in Appendices D, E, and F, respectively. 

C. THE DOCUMENTATION 

Each subject received a set of instructions which 
describes the background, scope and procedures for the gaming 
interface. This documentation gives the subject a clear 
understanding of his/her role in the experiment, explains the 
status report screens (an example is shown in Figure 2-2) , and 
presents procedures for running the TEST simulation as well as 
unique instructions for the specific experimental version. 
The background and instructions were the same for both groups; 
the only difference in the documentation was the batch 
filename (EXPl or EXP2) in the EXPERIMENT portion of the 
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instructions that the subject is directed to enter once the 
TEST simulation is completed. 

This documentation was provided to each subject prior to 
moving to the computer laboratory for the TEST simulation and 
actual experiment. It was thoroughly discussed, and all 
questions about its contents were answered before any subjects 
began the experiment. The subjects were directed verbally and 
in the instructions to run the TEST simulation first, and were 
told not to write any estimates or staffing decisions down 
while running TEST. As previously stated, the TEST simulation 
mirrored the actual experiments, without revealing their 
content or nature. The TRIAL RUN and EXPERIMENT instructions 
portion of the documentation gave each subject step-by-step 
directions and the unique batch filename for initiating their 
particular experiment (EXP1 or EXP2) once they stopped the 
TEST simulation after two time periods (80 days). A copy of 
the documentation and instruction set is in Appendix G. 

The final page of the documentation, the staffing level 
and project cost estimate record sheet, provides the 
researcher a means of capturing the staffing level and cost 
estimate decisions made by each subject. This page identifies 
the initial estimates of the size (396 tasks, where a task is 
approximately 50 lines of code), cost (1,111 man days) and 
duration (320 days) of the project, as well as the size of the 
initial core team (5 people) . It also specifies when a 
project is considered 'complete' (when "% Reported Complete" 
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equals 100 for both Development (Design and Coding) and 
Testing) , and provides blank spaces for project cost estimates 
and staffing level decisions to be recorded by the subject for 
each time period. A copy of this record sheet is in 
Appendix H. 

D. THE TRIAL EXPERIMENT 

Once the gaming interface and documentation were prepared, 
trial experiments were conducted to provide feedback on 
potential design or procedural problems. Four students who 
had knowledge of personal computers were selected to play the 
'game' as trial experiments. The objective of the trial 
experiment was to measure the individuals' interaction with 
the gaming interface and the documentation. Additionally, 
these students would become laboratory assistants for the 
conduct of the actual experiment, so their participation in 
the trial experiment served to give them hands-on experience 
with the experiment and the interface itself. Specific 
concerns to be examined in the trial experiment were: 

• Are the instructions clear? 

• Are the subjects comfortable with the gaming interface? 

• How long does the experiment take? 

• What are the questions the researcher and lab assistants 
need to be prepared to answer? 

• Two of the subjects of the trial experiment used the EXPl 
gaming interface (gradual increase in size), while the 
other two subjects used the EXP2 interface (sudden change 
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in requirements). Two subjects were not provided a trial 
run while the other two subjects used the TEST simulation 
before going on to the actual experimental versions. 
Pertinent observations and lessons learned were: 

• Average time for the experiment was 45 minutes, including 

instruction review, simulation, and saving information to 
disk. Inclusion of the TEST simulation added 

approximately 10 minutes to the experiment's duration. 

• The first two subjects, who did not have the TEST trial 
run, expressed a need for one, saying that they had 
thought that the first two time periods were a trial run. 
They also said that the trial run's start and finish 
should be clearly delineated in the written and on-screen 
directions, to preclude confusion. The two subjects who 
ran the TEST simulation felt more comfortable with the 
actual experiment than the two who had not, and had no 
problems transitioning from the TEST simulation to the 
actual experimental version. 

• One subject expressed a need for scrap paper on which to 
perform calculations. Although the scrap paper was 
provided, all subjects in the actual experiment were told 
to rely on their judgement as opposed to standard metrics, 
such as COCOMO. 

• Heuristics and metrics techniques presented in the ongoing 
Software Development class from which all of the subjects 
came were a stumbling block for two of the four subjects. 
The information presented in the initial estimates and the 
status reports conflicted with what the course had taught 
them to expect. They recommended that reliance on 
judgement, rather than metrics, be stressed in the initial 
briefing and during the conduct of the experiment. 

• One of the subjects, who ran the EXP2 simulation (sudden 
increase in size), did not react at first to the change, 
as he thought it was caused by something he had done. To 
remedy this, the warning screen alerting the subject to 
the change in requirements was made larger, and preceded 
by a notice to pay attention to the next screen. 

• Computers equipped with a math coprocessor and/or 80386 
microprocessors performed the simulations and provided 
faster response to subjects than those machines not so 
equipped. To reduce the response time as much as 
possible, only computers with hard drives would be used, 
and, to the extent possible, only those equipped with math 
coprocessors and/or 80386 microprocessors. 
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E. FINAL PREPARATIONS 

The changes noted in the lessons learned were implemented 
in the gaming interface and documentation, and the initial 
briefing included the emphasis on individual judgement rather 
than metrics. Group GRADUAL was defined as the group of 
subjects that would 'play' the EXP1 (gradual size increase) 
simulation, while Group ABRUPT would be the group of subjects 
using the EXP2 (sudden size increase) simulation. As 
indicated before, the difference in the simulations occurred 
within the Dynex control file, and was transparent to the 
subject. 

The final copies of the documentation for the two groups 
differed only in the batch filename that was provided to start 
the actual experiment; all other guidelines, information and 
record sheets were identical. A folder was prepared for each 
subject; it included a copy of the documentation, scrap paper, 
a survey addressing the subject's academic and work 
experience, and a diskette that contained the TEST and 
appropriate experimental version (EXP1 or EXP2) simulation 
programs. Additional preparations included assuring the 
availability of the computer laboratories, ascertaining 
individual computer status, loading of required files on the 
hard drives of the computers and preparing schedules and 
seating charts. 
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III. CONDUCTING TEE EXPERIMENT 


A. TASKS AND PROJECT CHARACTERISTICS 

The research subjects, having received the initial 
briefing two days prior to the actual experiment, were 
familiar with the skills expected of a software project 
manager. Experiencing the TEST simulation trial run 
immediately prior to the actual experiment ensured that they 
were familiar with the gaming interface itself. 

The two experiment simulation scenarios, EXPl and EXP2, 
were designed to allow the experimental subjects to make two 
decisions for each 40-day time period, based on the initial 
information and status reports they received from the 
simulations, until the completion of the project. The first 
decision they were prompted to make was to update the 
project's total cost estimate (in man days). The second 
decision was to determine a desired staffing level for the 
rest of the project. The project manager's role was stressed 
as that of resource manager; allocating resources as necessary 
to complete the project on time and within the projected 
budget, as close as possible to the original estimates. 

Subjects used the gaming interface to enter their 
decisions for each time period, and were provided with a 
status report. This report was designed in a text format. 
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which also allowed the data in each status report, as well as 
the final cost and schedule data for each subject, to be 
captured by the interface. In this fashion, staffing and cost 
estimate decisions were captured by the interface as well as 
on the subject-completed record sheet. 

B. ORGANIZING THE EXPERIMENT 

The experimental setting consisted of a 15-minute 
classroom training session in which the documentation, seating 
assignments and guidelines were presented and questions 
resolved. Due to the size of the groups and the limited 
number of acceptable computers within each laboratory, two 
different laboratories were used, with one laboratory 
assistant in each. The assistants answered general questions 
about the procedure or gaming interface, but did not answer 
questions about the actual decisions to be made. When asked 
about relative importance of schedule or cost, the assistants 
merely reiterated the guidance contained in the documentation; 
as close as possible to the original estimates of schedule and 
budget. The subjects received their individual folders at the 
beginning of the training session, and were directed to their 
respective seating locations once in the laboratories. In 
order to avoid inadvertent sharing of status report or other 
information, the seating ensured alternation of Group GRADUAL 
and Group ABRUPT players in the laboratory. Additionally, 
subjects were instructed to perform their own work and 


17 





informed that since several versions of the simulation were 
being used, anyone else's data or decisions could be 
misleading. Each laboratory assistant had a full set of 
backup diskettes and instructions so that any problem could be 
immediately resolved, and backup computers were designated on 
the seating chart in the event of a system malfunction. 

C. THE SAMPLE POPULATION 

The subjects for this experiment were students from a 
graduate level software engineering and management course, 
IS-4300, at the Naval Postgraduate School in Monterey, 
California. The course was divided into two sections; 
Segment 1 consisted of 28 students, and Segment 2 consisted of 
27 students. After the names of the researcher and the 
laboratory assistants were removed from the course rosters, 
the following matched sample procedure was followed to 
randomize the sample population and assign them to 
experimental groups [Ref. 6]. 

A two-level randomization was perfomed using an 
alphabetical list of students in each segment and a standard 
table of random digits [Ref. 7]. The population randomizing 
worksheet used for each section is at Appendix I. Column A is 
the alphabetical list of the students in each section; Column 
B is a two-digit random number taken from the standard table 
of random numbers and assigned to each student. The random 
numbers for Segment 1 were assigned beginning with row 20 of 



the table; random numbers for Segment 2 were assigned 
beginning with row 14. The list of students for each segment 
was then sorted into ascending order of random number. This 
randomized the alphabetical list in the first level (Column 
C) . These first level randomized lists were then assigned 
random numbers from the table; Segment 1 with numbers 
beginning with row 9, and Segment 2 with numbers beginning 
with row 37 of the table (Column D) . This list was again 
sorted into ascending order of random number, randomizing the 
original alphabetical list to the second level (Column E) ; 
this list was then used to make assignments to Groups GRADUAL 
and ABRUPT by alternating the group assignments (Column F). 

A total of 50 subjects were scheduled to participate in 
the experiment; 25 in each group. One subject was ill and 
unable to participate, so was dropped from the sample 
population. One subject, in 'playing' the game, misunderstood 
the instructions and repeatedly pressed the numeric key "l" 
instead of entering his desired staffing level, thereby 
nullifiying his decisions; he was also dropped from the sample 
population. These students are designated in Appendix I by 
the shading of their names. Both had been assigned to the 
GRADUAL Group, so the final sample populations used in the 
experiment consisted of 23 subjects in Group GRADUAL and 25 
subjects in Group ABRUPT. 


19 






D. DEPENDENT MEASURES 

Under certain sequences the Dynamo gaming interface does 
not allow some projects to reach design and testing completion 
of 100 percent; the simulation signifies completion by 
repeating status report information and showing an elapsed 
time that is not a multiple of the 40 day period, with only 
about 97 percent completion of design and testing. The 
general heuristic used to verify simulation completion was the 
observance of the 97 percent completion report and the 
irregular elapsed time figure. 

1. Process Variables 

The first process dependent variable was the project 
cost estimate made by each subject at the end of each time 
period. The line on the Status Report Screen from Appendix E 
which reads "Updated Estimate of T.-tal Man Days" mirrors the 
cost estimate made by the subject for that time interval. 

The second process dependent variable collected as a 
point of comparison was the actual staffing level decisions 
made by each subject at the end of each time interval. This 
variable was not reflected in the Status Report. Each subject 
decided on and recorded staffing level needs on the 
documentation sheet before entering them into the computer. 
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2. Performance Variables 

The subjects' performance was operationalized in terms 
of three variables: cost, schedule and combined cost and 

schedule. 

The first dependent variable measured as an output of 
the simulation was final cost. The line on the Status Report 
Screen in Figure 2-2 which reads "Total Man Days Expended to 
Date" is the cost of the project at the end of the given 
reporting period; upon completion of the simulation, this 
value is compared with the original project cost, and the 
dependent variable DIFFCOST is calculated as a percentage 
deviation from the original project cost [(COST + ORIGINAL 
COST) / ORIGINAL COST] represents the final project cost. 

The second dependent variable measured as an output of 
the simulation was the final schedule. The line on the Status 
Report Screen from Appendix E which reads "Elapsed Time" 
specifies the final schedule upon completion of the 
simulation. This value is compared with the original project 
schedule, and the dependent variable DIFFSKED is calculated as 
a percentage deviation from the original project schedule 
[(SCHED + ORIGINAL SCHED) / ORIGINAL SCHED]. 

The third performance dependent variable COSTSKED was 
the average combined difference from the original estimates of 
cost and schedule [DIFFCOST + DIFFSKED) / 2]. 
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IV. EXPERIMENTAL RESULTS AND ANALYSIS 

A. PREPARATORY ANALYSIS 

1. Model of Analysis 

The raw experimental data produced a final cost and 
schedule for each project manager, as well as their staffing 
level and cost estimate decisions for each time interval. 
Analysis of the data is based on the comparison of decisions 
and performance between the two groups, GRADUAL (gradual 
increase in project size) and ABRUPT (sudden increase in 
project size). 

The SAS General Linear Models (GLM) procedures were 
used for Univariate and Multivariate Analyses of Variance and 
for Repeated Measures analysis due to the inequal populations 
involved (22 subjects in the GRADUAL Group, 25 subjects in the 
ABRUPT Group) . The raw data is presented in Appendix J as the 
data portion of the SAS control files; it includes the name of 
the subject, his/her group (GRADUAL or ABRUPT) , and the 
individual's final schedule and final cost. 

2. Subjects 

a. Student Grade Distribution 

Students were randomly assigned to either of two 
groups as described in a previous chapter. There were no 
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significant differences between the two groups with respect to 
student ability, as reflected in their end of course grades 
(Sig of F = 0.3497). 

Jb. Outliers 

Preliminary SAS data analysis was performed on the 
raw data, and revealed one subject whose final cost did not 
fall within three standard deviations of the mean COST (three 
standard deviations is accepted by statistical texts as 
representing 99% of the observations). The subject's process 
and performance data was therefore excluded from all analyses, 
resulting in a total of 22 GRADUAL Group subjects and 
25 ABRUPT Group subjects. 

B. PROCESS MEASURES ANALYSIS AND RESULTS 

Following the approach suggested by Winer [Ref. 7], 
multivariate analysis of variance for repeated measures 
analyses were performed on staffing level and cost estimate 
decisions. The staffing level decision data for comparison of 
the GRADUAL and ABRUPT Groups are in Appendix K, in the data 
section of the SAS control file. The project cost estimate 
decision data for Groups GRADUAL and ABRUPT are in Appendix L, 
in the data section of the SAS control file. 

1. Staffing Level Decisions 

The mean staffing level decisions for each time period 
by group are plotted in Figure 4-1. The patterns of staffing 
decisions identified in Figure 4-1 support Hypothesis la. 
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As a group, those subjects presented with a sudden 
increase in project size (ABRUPT Group) reacted quickly by 
increasing staff levels by a significantly larger amount than 
the group experiencing a gradual increase in project size. 
Additionally, the trend after the initial increase was one of 
gradually declining levels, and an earlier completion date 
(schedule). 


STAFFING LEVELS vs INTERVALS 

GRADUAL AND ABRUPT GROUPS 



Figure 4-1 Staffing Level Decisions 

In contrast, the GRADUAL Group means reflect a sharp 
increase in staff levels through the second time period (day 
80) , a slight decrease for two time periods, a slight rise and 
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fall in the next two time periods, and then a drastic increase 
at Day 240, followed by an equally drastic decrease at 
Day 320. Analysis of the raw data for Day 280 revealed a 
reduced number of observations being averaged, five of the 
subjects having already completed the project. Additionally, 
one subject's staffing level decision (29 people) at Day 280 
skewed the entire curve. His rationale for this sudden 
increase was, "I was close to the scheduled completion date, 
and was behind in tasks reported complete, so I doubled my 
staffing level." The "ADUSTED GRADUAL GROUP" curve on the 
graph shows the effect of his decision by omitting his 
decision value from the computation of the interval's mean 
staffing level. The staffing level curve then continues its 
slight increase/decrease tendency which began at Day 160 
through the final interval (Day 320). The mean completion 
date for Group GRADUAL was approximately forty days later than 
that of Group ABRUPT, as indicated by the endpoints of the 
graph. 

Results from the multivariate analysis of variance 
performed on staffing level decisions shown in Table 4-1 
further support Hypothesis la. They show that the overall 
staffing patterns of subjects across the two groups were 
significantly different across time (P < 0.05). There was no 
significant between subjects effect; overall decisions of 
subjects were not significantly different across the two 
groups (P > 0.1). The Within Subjects results of the MANOVA 




shown in Table 4-1 support the findings of the previous 
paragraph. The MANOVA shows significant INTERVAL effect 


TABLE 4-1 SUMMARY OF STAFFING LEVEL DECISIONS REPEATED 
MEASURES ANALYSIS 1 


1 SOURCE OF 

1 VARIATION 

s. s. 

d.f. 

F 

Sig of F 

1 BTWN SUBJ 





| Group 

24.4489 

1 

2.26 

0.1398 

| Subj w/in 
| Group 

453.3894 

42 








W/IN SUBJ 





Interval 

0.7426 

5,38 

2.6343 

0.0386 

Intvl*Grp 

0.6612 

5,38 

3.8936 

0.0060 


(P < 0.05), indicating that all subjects made different 
decisions as time evolved. In addition, the interaction, or 
INTERVAL*GROUP effect is significant (P < 0.05), indicating 
that the pattern of the decisions made differed significantly 
over time between the two groups. 

2. Subjects' Cost Estimate Decisions 

The mean cost estimates for each time period by group 
are plotted in Figure 4-2. The project cost estimates for 
each of the 47 subjects are presented in Appendix L as the 
data section of the SAS control file. Cost estimate decision 


*Degrees of freedom are reduced because of the number of 
observations ignored by the Repeated Measures analysis due to 
missing values (subjects had already completed the project). 
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ESTIMATED COST vs INTERVAL 


GRADUAL AfC ABRUPT GROUPS 



INTERVAL CDATED 

a GRADUAL GP COST EST + ABRUPT GP COST EST 


Figure 4-2 Cost Estimate Decisions 


patterns identified by the graph support Hypothesis lb. 

The mean cost estimates for each group closely 
parallel each other until after Day 80, when the ABRUPT Group 
mean estimate jumps sharply while the GRADUAL Group mean 
continues a smooth climb. This reflects the sudden change in 
project size just revealed to the ABRUPT Group managers. 
After the initial sharp increase, the ABRUPT Group managers 
lower their estimates for two time periods in a row, just as 
the GRADUAL Group managers begin to increase the rate of their 
estimate growth. At Day 200, both groups increase their 
estimates, presumably in response to the advent of the 
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scheduled completion date in three time periods. However, 
GRADUAL Group maintains a consistent increase while ABRUPT 
Group increases their estimates sharply, as they had after 
Day 80, and then holds the estimate steady for the final time 
period. The pattern revealed in this figure shows a smooth, 
consistent increase in the GRADUAL Group estimate, while the 
ABRUPT Group is characterized by abrupt, spiky increases and 
decreases. While the response of the ABRUPT Group to the 
sudden increase in project size at Day 100 is obvious, the 
reason for the similar increase at Day 200 is less so. 

Results from the multivariate analysis of variance 
performed on cost estimate decisions shown in Table 4-2 
further support Hypothesis lb showing that the overall cost 

TABLE 4-2 SUMMARY OF COST ESTIMATE DECISIONS REPEATED 
MEASURES ANALYSIS 2 


SOURCE OF 
VARIATION 

s.s. 

d.f. 

F 

Sig of F 

BTWN SUBJ 





Group 

2238451.4 

1 

6.31 

0.0160 

Subj w/in 
Group 

14908267 

42 








I W/IN SUBJ 





Interval 

0.3026 

5,38 

17.5114 

0.0001 I 

Intvl*Grp 

0.7083 

5,38 

3.1296 

0.0184 1 


2 see Footnote 1. 
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estimate patterns of subjects across the two groups were 
significantly different across time (P < 0.05). There was a 
significant between subjects effect; within a given interval, 
the values differed significantly between groups (P < 0.05) 

The Within Subjects results of the MANOVA shown in Table 
4-2 support the findings of the previous paragraph. The 
MANOVA shows significant INTERVAL effect (P < 0.05), 

indicating that all subjects made different decisions as time 
evolved. In addition, the interaction, or INTERVAL*GROUP 
effect is significant (P < 0.05), indicating that the pattern 
of the decisions made differed significantly over time between 
the two groups. 

C. PERFORMANCE MEASURES ANALYSIS AND RESULTS 

This area of comparison involves the final cost and 
schedule for each group (Groups GRADUAL and ABRUPT) as a 
whole. Table 4-3 shows the means and standard deviation of 
DIFFCOST, DIFFSKED and COMBINED DIFF. These values show that 
GRADUAL Group (gradual increase in project size) has a higher 
mean value for DIFFSKED, indicating that they were farther 
from the initial estimated schedule than the ABRUPT Group 
(sudden increase in project size), and a lower mean value for 
DIFFCOST, indicating they were closer to the original cost 
estimate than the ABRUPT Group. The ABRUPT Group had a lower 
combined difference mean, indicating that, on average, they 
were closer to the original estimates than the GRADUAL Group. 





The recurring theme, however, is that regardless of how the 
change was presented, budget was forsaken in favor of meeting 
the schedule. 

Results of the MANOVA performed on DIFFCOST and DIFFSKED 
are shown in Table 4-4. They suggest that there was a 
significant difference in performance between the two groups 
if a 0.10 level of significance is applied for rejecting the 


TABLE 4-3 PROJECT COST AND SCHEDULE MEANS AND STANDARD 
DEVIATION BY GROUP 


Group 

Variable 

MEAN 

STD DEV 

GRADUAL 

DIFFCOST 

0.4736 

0.1105 

DIFFSKED 

0.0145 

0.1513 

COMBINED DIFF 

0.2441 

0.0819 

ABRUPT 

DIFFCOST 

0.4962 

0.0908 

DIFFSKED 

-0.0930 

0.1607 

COMBINED DIFF 

0.2016 

0.0752 


hypothesis. If a more strict 0.05 level is applied, however, 
the null hypothesis cannot be rejected. The results suggest 
moderate, but not strong support for hypothesis 2. 


TABLE 4-4 MULTIVARIATE ANALYSIS OF VARIANCE FOR SCHEDULE AND 
COST 


| Lambda 

df(num) 

df(den) 

F 

Sig of F H 

| 0.8846 

2 


2.94 

0.0634 | 
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The results of the univariate analysis of variance for 
DIFFSKED in Table 4-5 support Hypothesis 2 in terms of 
schedule (P < 0.05). However, the results of the univariate 
analysis of variance for DIFFCOST do not support Hypothesis 2 
in terms of cost performance (P > 0.05) . A univariate 
analysis of variance was also performed on the combined 


TABLE 4-5 UNIVARIATE ANALYSIS OF VARIANCE OF COST, SCHEDULE 
AND COMBINED DIFFERENCE 


VARIABLE 

CD 

CD 

• 

d.f. 

F 

Sig of F 

DIFFCOST 

0.0042 

l 

0.15 

0.7042 

DIFFSKED 

0.1135 

l 

4.53 

0.0387 

COMBINED 

0.0403 

l 

4.65 

0.0363 


differences from the original estimates, COMBINED. Results of 
this analysis are also displayed in Table 4-5, and indicate 
strong support for Hypothesis 2 (P < 0.05). 
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V. CONCLUSIONS 


A. SUMMARY OF FINLiNGS 

The single-project experiment was conducted using a 
properly randomized sample population, verified by statistical 
analysis of grade distribution of the the subjects in their 
assigned groups. The population was examined for outliers 
that would skew the results; one was detected and deleted from 
results analysis. The specific findings of the experiment are 
described below. The measure of performance is defined as the 
ability of each project manager to meet the original estimates 
of time and schedule. 

• Project managers of a system which roughly doubles in size 
during its lifecycle make different decisions on staffing 
and cost estimates when given the change abruptly than 
when presented with the change in gradual increments. 

• Project managers of a system which roughly doubles in size 
during its lifecycle perform better in terms of cost and 
schedule when given the change abruptly than when 
presented with the change in gradual increments. 

In all cases, the deviation of the final schedule from the 
original schedule was less than the deviation of the final 
cost from the original cost, indicating that if sufficient 
staff resources are available, managers will jeopardize 
maintaining budget goals in order to achieve a given schedule. 










The decision trends of the groups indicate that the 
GRADUAL groups reacted more slowly to the changes in size, 
using fewer resources initially and increasing both staff size 
and cost estimates rapidly near the end of the lifecycle. 
The ABRUPT group displayed a tendency to use greater resources 
upon learning of the change in size, and decreasing staff size 
and cost estimates near the end of the lifecycle. 

B. IMPLICATIONS 

Use of resources depends as much on the knowledge of when 
and how many resources will be required as on the knowledge of 
the task to be performed. Although our knowledge of a 
project's complexity and/or size may be imperfect, the more 
information we have about the scope of the project early on, 
and about its actual progress will improve the performance and 
efficiency of the project. Although the reactions of the 
ABRUPT group were more pronounced than those of the GRADUAL 
group, the end result was improved performance in terms of 
schedule, if not cost as well. 

C. FUTUR E RESEARCH EFFORTS 

System dynamics and its effects on project management are 
of crucial importance in understanding and improving processes 
and performance. Use of the SDM gaming interface to 
investigate the effects of improved visibility, estimates and 
reporting procedures lends itself to several research efforts. 
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A logical followup to this experiment would be to examine the 
effects of improved visibility at early-, mid- and late- 
intervals in the lifecycle of the project to determine where 
it is crucial, where it is helpful, and where it is 
deleterious to the success of the project. 
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APPENDIX A: TEST DYNEX FILE 


if #tm<0.9 then 
display clear 


********* EXPERIMENT TRIAL RUN ********* 

Important Points to Remember !!!!!!!!! 
************************************** 


- You are not allowed to discuss this exercise with anyone 
other than a lab attendant. Please refrain from discussing 
this with other class members until they have completed the 
project. 

- The system will run through the first simulation period 
(2 months) and provide you with a status report. At the end 
of each reporting period, you will have an opportunity to 
revise the estimated total project cost (in man days), and to 
revise your desired staff level. 

- In this trial run, you do not have to annotate the 
documentation sheet. Use the trial run for two time periods 
to familiarize yourself with the experiment procedures. 

- Press <ENTER> to continue 
dendq 

choice 1 
cend 1/1 
else 

choice 1 
cend 1/1 
display clear 

INPUT YOUR ESTIMATE OF THE TOTAL PROJECT COST IN MAN 

DAYS 

*********************************************************** 


1) Press <ENTER> to maintain your last cost estimate 


***** OR ***** 

2) Enter your new estimate of total project cost (in 
man days) 

and press <ENTER>. 
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Your last project cost estimate was = 

dendq 

dq TOTMD1=0<100000 
display clear 


!!!!!!!! WARNING !!!!!!!! 

Make sure that you have written your project cost 
estimate down on the project documentation sheet 
before continuing with the simulation. 

This is your final chance to change your estimated 
total project cost. Press <ENTER> to keep the same 
estimate or enter a new cost estimate and then press 
<ENTER>. 

The updated estimate of total project cost is = 

dendq 

dq TOTMD1=0<100000 
display clear 


INPUT YOUR DESIRED STAFFING LEVEL 
*********************************** 


1) Press <ENTER> to maintain your last desired staffing 
level. 

********* OR ********* 

2) Enter the new desired staffing level and press 
<ENTER>. 


Your last desired staffing level was = 
dendq 

dq WFS1«= 0<100 
display clear 


!I!1!WARNING!!!!! 

Make sure that you have written your staffing 
level decision down on the project documentation 
sheet before continuing with the simulation. 
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This is your final chance to change your 
staffing level for this time period. Press 
<ENTER> to keep the same number or enter a 
new staffing level and press <ENTER>. 


The current staffing level = 
dendg 

dq WFS1= 0<100 
end 

display clear 

Press <ENTER> to simulate the next time interval. 

dendq 
choice 1 
REPORT 

time=maxtime, 

FORMAT="40-" 

"PROJECT STATUS REPORT";; 

Format*"20<,54<,66c",PICTURE*"Z,ZZ9V" 

"ELAPSED TIME ======== = >",tm,"Days";; 

Format="5<" 

"ESTIMATES MADE AT THE START OF THE PROJECT"; 

FORMAT="8<,52<,66<",PICTURE*"ZZZ,ZZZV" 

"Project Size",IPRJSZ,"Tasks"; 

FORMAT*"8<,52<,66<",PICTURE="ZZZ,ZZZV" 

"Project Cost in Man Days",TOTMDO,"Man Days"; 

FORMAT*"8 <,52<,66<",PICTURE*"ZZZ,ZZZV" 

"Project Duration",TDEVl,"Days"; 

Format*"5<,52<,66<", PICTURE*"ZZZ,ZZ9V" 

"PROJECT STATUS at Time =========== = >",tm,"Days"; 

FORMAT*"8<,52<,66<",PICTURE*"ZZZ,ZZ9V.99" 

"Updated Estimate of Total Project Size",PJBSZ,"Tasks"; 
FORMAT*"8<,52<,66<", PICTURE*"ZZZ,ZZ9V.99" 

"% Development (Design & Code) Reported 
Complete",PDVRC,"Percent"; 

FORMAT*"8<,52<,66<",PICTURE*"ZZZ,ZZ9V.99" 

"% Testing Reported Complete",PTKTST*100,"Percent"; 

FORMAT*"8<,52<,66<",PICTURE*"ZZZ,ZZ9V.99" 

"Updated Estimate of Total Man Days",JBSZMD,"Man Days"; 
FORMAT*"8<,52<,66<", PICTURE*"ZZZ,ZZZV.99" 

"Total Man Days Expended to date",CUMMD,"Man Days"; 

FORMAT*"8<,52c,66<", PICTURE*"ZZZ,ZZ9V" 

"Updated Est. of Project Duration (start-end)",SCHCDT,"Days"; 
FORMAT-"8<,52<,66<",PICTURE*"ZZZ,ZZ9V.9" 

"Current Staff Size",FTEQWF,"Fulltime Staff"; 

FORMAT-"5<" 

"PRESS <ENTER> TO RETURN TO MENU" 
cend 1/1 

spec md_length-#length+40 
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APPENDIX B: EXP1 DYNEX FILE 


if #tm<0.9 then 
display clear 


Important Points to Remember !!!!!!!!! 

************************************** 

- You are not allowed to discuss this exercise with anyone 
other than a lab attendant. Please refrain from discussing 
this with other class members until they have completed the 
project. 

- The system will run through the first simulation period 
(2 months) and provide you with a status report. At the end 
of each reporting period, you will have an opportunity to 
revise the estimated total project cost (in man days), and to 
revise your desired staff level. 

-Make your changes to the cost estimate and the desired 
staffing level both on the documentation sheet provided and on 
the screen. 

A LAB ATTENDANT MUST VERIFY YOUR FINAL RESULTS! 

- GOOD LUCK! Press <ENTER> to continue, 
dendq 

choice 1 
cend 1/1 
else 

choice 1 
cend l/l 

display clear 


INPUT YOUR ESTIMATE OF THE TOTAL PROJECT COST IN MAN 

DAYS 

*********************************************************** 


1) Press <ENTER> to maintain your last cost estimate 

******** OR ******** 
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2) 

days) 


Enter your new estimate of total project cost (in man 
and press <ENTER> 


Your last project cost estimate was = 
dendg 

dq TOTMD1=0<100000 
display clear 


!!!!!!!! WARNING !!!!!!!! 


Make sure that you have written down your project 
cost estimate down on the project documentation 
sheet before continuing with the simulation. 

This is your final chance to change the estimated 
total project cost. Press <ENTER> to keep the same 
estimate or enter a new cost estimate and then press 
<ENTER>. 

The updated estimate of total project cost is = 
dendq 

dq TOTMD1=0<100000 
display clear 


INPUT YOUR DESIRED STAFFING LEVEL 
*********************************** 


1) Press <ENTER> to maintain your last desired staffing 
level. 

********* or ********* 

2) Enter the new desired staffing level and press 
<ENTER>. 

Your last desired staffing level was - 
dendq 

dq WFS1* 0<100 
display clear 


!!!! I WARNING! ! Ml 

Make sure that you have written your staffing 
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level decision down on the project documentation 
sheet before continuing with the simulation. 

This is your final chance to change your 
staffing level for this time period. Press 
<ENTER> to keep the same number or enter a 
new staffing level and press <ENTER>. 


The current staffing level = 
dendg 

dq WFS1* 0<100 
end 

display clear 

Press <ENTER> to simulate the next time interval. 

dendq 
choice 1 
REPORT 

t ime*maxt ime, 

FORMAT**"40- " 

"PROJECT STATUS REPORT";; 

Format**"20<, 54< f 66<" , PICTURE**"Z, ZZ9V" 

"ELAPSED TIME ======== =>",tm,"Days";; 

Format*"5<" 

"ESTIMATES MADE AT THE START OF THE PROJECT"; 

FORMAT*"8<,52<,66<",PICTURE*"ZZZ,ZZZV" 

"Project Size",IPRJSZ,"Tasks"; 

FORMAT*"8<,52<,66<",PICTURE*"ZZZ,ZZZV" 

"Project Cost in Man Days",TOTMDO,"Man Days"; 

FORMAT*"8<,52<,66<",PICTURE*"ZZZ,ZZZV" 

"Project Duration",TDEVl,"Days"; 

Format*"5<,52<,66<",PICTURE*"ZZZ,ZZ9V" 

"PROJECT STATUS at Time =========== =>",tm,"Days"; 

FORMAT*"8<,52<,66<",PICTURE*"ZZZ,ZZ9V.99" 

"Updated Estimate of Total Project Size",PJBSZ,"Tasks"; 
FORMAT*"8<,52<,66<",PICTURE*"ZZZ,ZZ9V.99" 

"% Development (Design & Code) Reported 
Complete",PDVRC,"Percent"; 

FORMAT*"8<,52<,66<",PICTURE*"ZZZ,ZZ9V.99" 

"% Testing Reported Complete",PTKTST*100,"Percent"; 

FORMAT-"8<,52<,66<",PICTURE-"ZZZ,ZZ9V.99" 

"Updated Estimate of Total Man Days",JBSZMD,"Man Days"; 
FORMAT*"8<,52<,66<", PICTURE*"ZZZ,ZZZV.99" 

"Total Man Days Expended to date",CUMMD,"Man Days"; 

FORMAT*"8<,52<,66PICTURE*"ZZZ,ZZ9V " 

"Updated Est. of Project Duration (start-end)",SCHCDT,"Days"; 
FORMAT-"8<,52<,66<", PICTURE-"ZZZ,ZZ9V.9" 

"Current Staff Size",FTEQWF,"Fulltime Staff"; 

FORMAT-"5<" 

"PRESS <ENTER> TO RETURN TO MENU" 
cend 1/1 

spec md_length-#length+40 
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APPENDIX C: EXP2 DYNEX FILE 


if #tm<0.9 then 
display clear 


Important Points to Remember !!!!•!!!! 

************************************** 

- You are not allowed to discuss this exercise with anyone 
other than a lab attendant. Please refrain from discussing 
this with other class members until they have completed the 
project. 

- The system will run through the first simulation period 
(2 months) and provide you with a status report. At the end 
of each reporting period, you will have an opportunity to 
revise the estimated total project cost (in man days), and to 
revise your desired staff level. 

- Make your change to the desired staffing level both on 
the documentation sheet provided and on the screen. 

A LAB ATTENDANT MUST VERIFY YOUR FINAL RESULTS! 

- GOOD LUCK! Press <ENTER> to continue, 
dendq 

choice 1 
cend l/l 
else 

choice 1 
cend 1/1 
display clear 

INPUT YOUR ESTIMATE OF THE TOTAL PROJECT COST IN MAN DAYS 

*********************************************************** 


1) Press <ENTER> to maintain your last cost estimate 

***** OR ***** 


2) Enter your new estimate of total project cost (in 
man days) 

and press <ENTER>. 
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Your last project cost estimate was = 

dendq 

dq TOTMDl-OclOOOOO 
display clear 


!!!!!!! 1 WARNING !!!!!!!! 

Make sure that you have written your project cost 
estimate down on the project documentation sheet 
before continuing with the simulation. 

This is your final chance to change your estimated 
total project cost. Press <ENTER> to keep the same 
estimate or enter a new cost estimate and then press 
<ENTER>. 


The updated estimate of total project cost is = 

dendq 

dq TOTMD1=0<100000 
display clear 


INPUT YOUR DESIRED STAFFING LEVEL 

*********************************** 


1) Press <ENTER> to maintain your last desired staffing 
level. 

********* or ********* 

2) Enter the new desired staffing level and press 
<ENTER>. 


Your last desired staffing level was = 
dendq 

dq WFS1- 0<100 
display clear 


MM l WARNING! !!! ! 

Make sure that you have written your staffing 
level decision down on the project documentation 
sheet before continuing with the simulation. 
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This is your final chance to change your 
staffing level for this time period. Press 
<ENTER> to keep the same number or enter a 
new staffing level and press <ENTER>. 


The current staffing level = 
dendg 

dq WFS1= 0<100 
if #tm <80 then 
display clear 

Press <ENTER> to simulate the next time interval. 

dendq 

else 

if #tm<120 then 
display clear 
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**** SPECIAL REPORT FOLLOWS **** 

PRESS <ENTER>, THEN READ CAREFULLY! 


dendq 
choice 1 
cend l/l 
display clear 
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YOUR PROJECT SIZE JUST INCREASED BY 54%! 


THE PREVIOUS PROJECT SIZE WAS #PJBSZ TASKS 

THE CURRENT PROJECT SIZE IS 609 TASKS 

Press <ENTER> to continue . . . 


dendq 
choice 1 
cend l/l 
display clear 

Press <ENTER> to simulate the next time interval. 

dendq 

else 

end 

end 

end 

display clear 

Press <ENTER> to simulate the next time interval. 

dendq 
choice 1 
REPORT 

t ime-maxt ime, 

FORMAT*"40 - " 

"PROJECT STATUS REPORT";; 

Format-"20<,54<,66<",PICTURE-"Z,ZZ9V" 

"ELAPSED TIME ======== ->",tm,"Days";; 

Format-"5<" 

"ESTIMATES MADE AT THE START OF THE PROJECT"; 

FORMAT-"8<,52<,66<",PICTURE-"ZZZ,ZZZV " 

"Project Size",IPRJSZ,"Tasks"; 

FORMAT-"8<,52<,66<", PICTURE-"ZZZ,ZZZV" 
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"Project Cost in Man Days",TOIMDO,"Man Days"; 

FORMAT®"8<,52<,66<",PICTURE®"ZZZ,ZZZV" 

"Project Duration",TDEV1,"Days"; 

Format="5<,52<,66<",PICTURE®"ZZZ,ZZ9V" 

"PROJECT STATUS at Time =========== =>",tm,"Days"; 

FORMAT®"8<,52<,66<",PICTURE®"ZZZ,ZZ9V.99" 

"Updated Estimate of Total Project Size",PJBSZ,"Tasks"; 
FORMAT®" 8<,52<,66< ",PICTURE®"ZZZ,ZZ9V.99" 

"% Development (Design & Code) Reported 
Complete",PDVRC,"Percent" ; 

FORMAT®"8<,52<,66<",PICTURE®"ZZZ,ZZ9V.99" 

"% Testing Reported Complete",PTKTST*100,"Percent"; 

FORMAT®"8<,52<,66<",PICTURE®"ZZZ,ZZ9V.99" 

"Updated Estimate of Total Man Days",JBSZMD,"Man Days"; 
FORMAT®"8<,52<,66<",PICTURE®"ZZZ,ZZZV.99" 

"Total Man Days Expended to date",CUMMD,"Man Days"; 

FORMAT®"8<,52<,66<",PICTURE®"ZZZ,ZZ9V" 

"Updated Est. of Project Duration (start-end)",SCHCDT,"Days"; 
FORMAT®"8<,52<,66<",PICTURE®"ZZZ,ZZ9V.9" 

"Current Staff Size",FTEQWF,"Fulltime Staff"; 

FORMAT®"5<" 

"PRESS <ENTER> TO RETURN TO MENU" 
cend l/l 

spec md_length=#length+40 
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APPENDIX D: TEST BATCH CONTROL FILE 


echo off 
CLS 

init 1 
GRAPHICS 
bat /N /p /s 

emit TEST -go = -prs * -Is -ns -plm 6 -bw 

-top dynex TEST -in TEST.STT -sc -Is -plm 6 -bw 
smlt TEST -gm = -ns -plm 6 -bw 
rep TEST -outf INTERVAL.OUT -t -bw >NUL 
rep TEST -bw >NUL 
infoofb 1 
Call -topi 
Exit 

goto -top%A 

-topi %A = l 

color \1F 

ram 

els 

begtype 


MAIN MENU 


\1F ENSURE YOU HAVE VIEWED THE PROJECT STATUS 

REPORT 

\lF FOR THIS TIME PERIOD PRIOR TO SELECTING OPTION 

#2 

\1D 1 \1F VIEW PROJECT STATUS REPORT 

\1D 2 \1F PROCEED TO SIMULATE NEXT TIME 

PERIOD 

Choose an option:\1C DO NOT HIT <ENTER> AFTER SELECTION!!) ; 

end 


-lstkeyl inkey %0 | if %0 # « 1 type %0; 
if %0 ■ key01b return 
goto -%0~1 
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-2ndkeyl inkey %1 | if %l # = 1 type %1; 
if %1 = keyOlb return 
if %1 = key020 goto -$%0$1 
if %1 = keyOOd goto -$%0$1 
if %1 = key008 goto -topi 
if %1 = keyl4b goto -topi 
goto -%0%11 

-1~1 **** VIEW PROJECT STATUS REPORT ******************** 

rep TEST TEST -outf TEST.OUT -t -sc Is -plm 6 -bw 
INKEY %0 

bat /p /s goto -topi 

-2~1 **** PROCEED WITH NEXT SIMULATION ******************** 

BAT CLS 
BAT COLOR \1F 
BAT BEGTYPE 

************************************************************ 


1. DETERMINE YOUR ESTIMATE OF TOTAL PROJECT COST (IN 
MAN DAYS) AND WRITE IT ON THE DOCUMENTATION SHEET. 

2. DETERMINE YOUR DESIRED STAFFING LEVEL AND WRITE IT 
ON THE DOCUMENTATION SHEET. 

3. PRESS <ENTER>. 


************************************************************. 

/ 

END 

bat /p /s goto -top 

-% 0~1 

-$% 0$1 

-%0%ll beep goto -topi 
-on.error- 

if %R > 82 if %R < 90 type !! Floating Point Error !! |goto 
-Calc. 

Cls beep type Unexpected batch file error %R in line %L (exit 
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APPENDIX E: EXP1 BATCH CONTROL FILE 


echo off 
CLS 

init 1 
GRAPHICS 
bat /N /p /s 

smlt EXP1 -go = -prs = -Is -ns -plm 6 -bw 

-top dynex EXP1 -in EXP1.STT -sc -Is -plm 6 -bw 
smlt EXP1 -gm = -ns -plm 6 -bw 
rep EXPl -outf INTERVAL.OUT -t -bw >NUL 
rep EXPl -bw >NUL 
infoofb 1 
Call -topi 
Exit 

goto -top%A 

-topi %A = 1 

color \1F 

ram 

els 

begtype 


\1A MAIN MENU 


\lF ENSURE YOU HAVE VIEWED THE PROJECT STATUS REPORT 

\1F FOR THIS TIME PERIOD PRIOR TO SELECTING OPTION #2 


\lD 1 \1F VIEW PROJECT STATUS REPORT 

\1D 2 \1F PROCEED TO SIMULATE NEXT TIME PERIOD 

Choose an option:\1C DO NOT HIT < ENTER > AFTER 
SELECTION!!) 
end 

-lstkeyl inkey %0 | if %0 # = 1 type %0; 
if %0 = keyOlb return 
goto -%0~l 

-2ndkeyl inkey %1 | if %l # = 1 type %1; 
if %1 = keyOlb return 
if %1 = key020 goto -$%0$1 
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if %1 = keyOOd goto -$%0$1 
if %1 = key008 goto -topi 
if %1 = keyl4b goto -topi 
goto -%0%11 

-1~1 **** VIEW PROJECT STATUS REPORT ******************** 

rep EXPl EXPl -outf EXP1.OUT -t -sc -Is -plm 6 -bw 
INKEY %0 

bat /p /s goto -topi 

-2~1 **** PROCEED WITH NEXT SIMULATION ******************** 

BAT CLS 
BAT COLOR \1F 
BAT BEGTYPE 


************************************************************ 

***** 

1. DETERMINE YOUR ESTIMATE OF TOTAL PROJECT COST (IN 
MAN DAYS) AND WRITE IT ON THE DOCUMENTATION SHEET. 

2. DETERMINE YOUR DESIRED STAFFING LEVEL AND WRITE IT 
ON THE DOCUMENTATION SHEET. 

3. PRESS <ENTER>. 


************************************************************ 

****** 

> 

END 

bat /p /s goto -top 

-% 0~1 

-$%0$l 

-%0%ll beep goto -topi 
-on.error- 

if %R > 82 if %R < 90 type !! Floating Point Error !! |goto 
-Calc. 

Cls beep type Unexpected batch file error %R in line %L |exit 
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APPENDIX F: EXP2 BATCH CONTROL FILE 


echo off 
CLS 
init 1 
GRAPHICS 
bat /N /p /s 

emit EXP2 -go - -prs = -Is -ns -plm 6 -bw 

-top dynex EXP2 -in EXP2.STT -sc -Is -plm 6 -bw 
smlt EXP2 -gm = -ns -plm 6 -bw 
rep EXP2 -outf INTERVAL.OUT -t -bw >NUL 
rep EXP2 -bw >NUL 
infoofb 1 
Call -topi 
Exit 

goto -top%A 

-topi %A = 1 

color \1F 

ram 

els 

begtype 


\1A MAIN MENU 


\1F ENSURE YOU HAVE VIEWED THE PROJECT STATUS REPORT 

\1F FOR THIS TIME PERIOD PRIOR TO SELECTING OPTION #2 


\1D 1 \1F VIEW PROJECT STATUS REPORT 

\1D 2 \1F PROCEED TO SIMULATE NEXT TIME PERIOD 

Choose an option:\1C DO NOT HIT <ENTER> AFTER SELECTION!!) ; 

end 

-lstkeyl inkey %0 | if %0 # * 1 type %0; 
if %0 ■ keyOlb return 
goto -%0~1 

-2ndkeyl inkey %1 | if %1 # = 1 type %1; 
if %1 *= keyOlb return 

if %1 = key020 goto -$%0$1 

if %1 - keyOOd goto -$%0$1 
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if %1 = key008 goto -topi 
if %1 = keyl4b goto -topi 
goto -%0%11 


-1~1 **** VIEW PROJECT STATUS REPORT ******************** 

rep EXP2 EXP2 -outf EXP2.0UT -t -sc -Is -plm 6 -bw 
INKEY %0 

bat /p /s goto -topi 

-2~1 **** PROCEED WITH NEXT SIMULATION ******************** 

BAT CLS 
BAT COLOR \1F 
BAT BEGTYPE 


************************************************************ 

1. DETERMINE YOUR ESTIMATE OF TOTAL PROJECT COST (IN 
MAN DAYS) AND WRITE IT ON THE DOCUMENTATION SHEET. 

2. DETERMINE YOUR DESIRED STAFFING LEVEL AND WRITE IT 
ON THE DOCUMENTATION SHEET. 

3. PRESS <ENTER> 


************************************************************ j 

END 

bat /p /s goto -top 

-% 0~1 

-$% 0$1 

-%0%ll beep goto -topi 
-on.error- 

if %R > 82 if %R < 90 type !J Floating Point Error !! (goto 
-Calc. 

Cls beep type Unexpected batch file error %R in line %L |exit 
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APPENDIX G: EXPERIMENT DOCUMENTATION AND INSTRUCTION SET 


YOUR NAME: 
SMC NO: 


INTRODUCTION 

The exercise you are about to undertake is similar in many 
ways to the flight simulators that pilots use to mimic flying 
an aircraft from takeoff at point A to landing at point B. 
Instead of the flight of an aircraft, though, this simulator 
mimics the life of a real software project from the start of 
the design phase until the end of testing . In this 
simulation, you will be more than an observer. In fact, you 
will play an important role on the project: that of the 
project manager. 

Specifically, your role will be to track the project's 
progress using a number of status reports that will be 
produced for you at two-month intervals (40 working days) 
during the project. As the project manager, you must then 
update the project's total cost estimate as well as determine 
the staff size based on the knowledge you gain from these 
reports. You can hire additional staff or decrease the 
staffing level as you deem necessary to complete the project. 


PROJECT 

The project that you will manage happens to have been a 
real project conducted in a real organization. The particular 
organization is on the leading edge in software engineering 
technology. For the project, you will be given a project 
profile containing the following initial information: 

Estimated Project Size(in Number of Tasks*) 

Estimated Duration(in Number of Work Days) 

Estimated Project Cost(in Number of Man Days) 

Size of Initial Core Team**(in Number of People) 

* A task is a software module that is approximately 50 
lines of code in size. 

** The Core Team is the group of software professionals 
that developed the project's requirement specifications. 
(Remember, you are taking over at the beginning of the 
Design Phase). 
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YOUR TASK 


Your task is to use the bi-monthly status reports to 
update the project's total cost estimate (in man days) and 
to determine a desired staffing level for the remainder of 
the project. Your objective in setting the staffing level 
should be to complete the project on schedule. 

Note, however, that finishing ahead of schedule will not 
gain you anything. In fact, it may hurt you, since 
finishing ahead of schedule will probably mean hiring more 
staff than needed, thus incurring a higher cost than 
required. 


SOME IMPORTANT THINGS TO CONSIDER IN MAKING YOUR ESTIMATES; 

1. This simulation mimics reality very closely. As real 
managers often do, you will have to use your judgement in 
coming up with your estimates. 

2. As you ponder whether or not you should update the 
project's cost (in man days), you will be relying on the 
status report information. This will provide you, for 
example, with: 

(a) Updated Estimate of Total Project Size (in Tasks) 

(b) % Development (Design and Code) Reported Complete 
(Percent) 

(c) Total Man Days Expended to Date (Man Days) 

3. As part of your task, you will specify the desired 
staffing level for the remainder of the lifecycle. You may 
find that the actual staff level may be somewhat different. 
This will be due to things you cannot totally control such 
as turnover and lengthy hiring delays. 

(a) The personnel turnover rate is 20% per year. 

(b) The hiring delay for new employees can take up to 6 
weeks. Once new people are hired, the training period for a 
newly hired employee is typically one month long. This is 
the time needed to train a new employee in the mechanics of 
the project and bring him/her up to speed. A new employee 
(i.e. one that is being trained) is only half as productive 
as an experienced employee. 

4. At different points in the project you will be given 
information on the status of the project. Three key pieces 
of information for your task are: 
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(a) The "Undated Estimate of Total Project Size" (this 
can change to reflect the addition of new requirements). 


(b) The "Total Man Days Expended to Date". Subtracting 
the "Total Man Days Expended to Date" from your "Updated 
Estimate of Total Man Days" yields the "Remaining Effort 
in Man Days." For example, if your "Updated Estimate of 
Total Man Days" is 1000 days, and the "Man Days Expended 
to Date" figure is 300 days, the Remaining Effort is 700 
man days. 

(c) The "Updated Estimate of Project Duration (start- 
end) " . In order to determine the "Remaining Time", you 
subtract the "Elapsed Time" from the "Updated Estimate 
of Project Duration (start-end)." For example, if the 
"Updated Estimate of Project Duration (start-end)" is 
200 days, and the "Elapsed Time" is 80 days, the 
Remaining Time is 120 days. It is important to note 
that this is an estimate which may or may not be totally 
reliable. 

This information could help you figure out, on the one hand, 
the number of tasks remaining, and on the other, your team's 
productivity (i.e., tasks developed per man day). But . you 
must remember that in this project (like in real projects), 
such status information (e.g., percent reported complete) 
may or may not be totally reliable. Typically, such status 
reports are not completely reliable in the earlier phases. 
However, as the project proceeds, visibility typically 
improves and with it, the reliability of information. The 
bottom line is: You will have to use your best judgement . 

5. As many projects do, the size of your project may change 
as the project proceeds (e.g., to reflect changes in user 
requirements). Again, you will have to use your judgement 
in using such changes to update your cost and staff. 

6. Let us say that at some point in the project the 
"Remaining Effort" is 1000 man days, the "Remaining Time" is 
100 days and you have 7 full time equivalent employees 
working. You are, thus, in a position where you have to use 
your judgement to do one of the following: 

1. Stick with the current schedule. You will need a 
staff size of 1000/100 = 10 full time employees. 

2. Stick with your staff size of 7. This means the 
schedule has to be pushed back. In this case the model 
will make the appropriate adjustment to the schedule for 
you. (For example, extend it to 1000/7 = 143 man days). 
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3. Do a bit of both. For example, increase the staff 
size to 8, which will also mean that the schedule will 
be extended appropriately by the model to 1000/8 = 125 
days. 
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1. TRIAL KPN 


(a) Do not start the network . From the C> prompt, 
change the directory to IS4300. 

(b) Type TEST to begin the trial run. 

(c) The system will show you some introductory screens 
and instructions. 

(d) The simulation will run through the first simulation 
time period and show you the "MAIN MENU". 

(e) DO NOT HIT ENTER AFTER MENU SELECTIONS . Press 1 to 
view the status report. Please be sure you understand 
it before continuing. 

(f) Press <ENTER> to return to the Main Menu. At the 
Main Menu, press 2 to prepare for another simulation. 

(g) The screen will prompt you to enter an estimate 
of total project cost and staff requirements before 
performing the next simulation. Perform steps (d) through 
(f) for as many intervals as necessary (by pressing 2 at the 
Main Menu), until you are comfortable with the system. Run 
the project for a minimum of 2 intervals. 

(h) After you are finished with the Trial Run, hit <ESC> 
when you are at the "MAIN MENU" screen to exit. This is 
the only time you should hit <ESC>. 

(i) Remain in IS4300 directory. Proceed to the 
experiment (Para 2). 

2. E XPERIMENT 

(a) Type EXP1 to run the project. 

(b) Follow instructions (c) through (f); ensure you 
write your estimates on the documentation sheet and 
enter them in the computer before proceeding with each 
interval simulation. 

(c) Your project is considered complete when "% Reported 
Complete"-100 for both development (e.g.. Design and 
Coding) and testing. 



APPENDIX H: EXPERIMENT DECISION RECORD SHEET 


Management's Initial Project Estimates 

Initial Estimate of Project Size: 396 Tasks 
Initial Estimate of Project Cost: 1,111 Man Days 
Initial Estimate of Project Duration: 320 Days 
Size of Initial Core Team: 5 People 

A project is considered complete when "% Reported Complete" 
= 100 for both development work (i.e., Design and Coding) 
and testing. 

Please enter your project cost estimates and staffing 
decisions below: 


PROJECT COST 


STAFFING(PEOPLE) 


Time 

elapsed 

- 

40 ( 

days: 

Time 

elapsed 

- 

80 ( 

days: 

Time 

elapsed 

- 

120 

days: 

Time 

elapsed 

- 

160 

days: 

Time 

elapsed 

- 

200 

days: 

Time 

elapsed 

- 

240 

days: 

Time 

elapsed 

- 

280 

days: 

Time 

elapsed 

- 

320 

days: 

Time 

elapsed 

- 

360 

days: 

Time 

elapsed 

- 

400 

days: 

Time 

elapsed 

- 

440 

days: 

Time 

elapsed 

- 

480 

days: 

Time 

elapsed 

- 

520 

days: 
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APPENDIX I: SAMPLE POPULATION RANDOMIZING WORKSHEET 


IS 4300 



SEGMENT 1 

A 

B 

C 

D 

E 

F | 

BOWMAN 

90 

YOUNGBLOOD 

36 

LOCKHART 

■9 

BROADWATER 

58 

ROSS 

52 

STEIN 

B 

BRYANT 

55 

MAIN 

06 

WRIGHT 

■9 

CHELOUCHE 

89 

CULPEPPER 

44 

HALE 

B 

CHICHESTER 

53 

FEY 

65 

MAIN 

■9 

CULPEPPER 

12 

HALE 

05 

CHICHESTER 

_ B J 

PEY 

21 

KROTOW 

55 

IVEY 

m 

FOOTE 

60 

WRIGHT 

03 

WHITE 

B I 

HALE 

25 

LOCKHART 

01 

SALTERS 

■9 

IVEY 

84 

STEELE 

57 

MCDONALD 


KROTOW 

29 

PASADILLA 

82 

YOUNGBLOOD 

■9 

LLANETA(ROGERS) 

95 

SALTERS 

24 

FOOTE 

B 1 

LOCKHART 

33 

WHITE 

23 

CULPEPPER 

■9 

MAIN 

10 

SOONG 

95 

ROGERS 

B 1 

MCDONALD 

67 

CHICHESTER 

20 

| ROSS | 

D 

PASADILLA 

38 

BRYANT 

69 

KROTOW 

B 1 

ROSS 

08 

BROADWATER 

75 

STEELE 

■9 

SALTERS 

42 

FOOTE 

37 

BOWMAN 

B | 

SOONG 

49 

MCDONALD 

26 

FEY 

■9 

STEIN 

80 

STEIN 

02 

BRYANT 

bJ 

WHITE 

43 

IVEY 

22 

CHELOUCHE 

■9 

WRIGHT 

32 

CHELOUCHE 

75 

BROADWATER 


YOUNGBLOOD 

00 

BOWMAN 

65 

PASADILLA 

■9 

STEELE 

34 

LLANBTA(ROGERS) 

49 

SOONG 

B 
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IS 4300 


SEGMENT 2 
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APPENDIX J: SAS DATA AND CONTROL FILES FOR MANOVA 


FINAL SCHEDULE AND COST 

OPTIONS LINESIZE=80; 

DATA; 

INPUT NAME $ GROUP $ SCHED COST; 
INICOST=llll.00; 

INISCHED=320; 

DIFFSKED®(SCHED-INISCHED)/INISCHED; 
DIFFCOST=(COST-INICOST)/INICOST; 
COSTSKED=(DIFFCOST+DIFFSKED)/2; 
CARDS; 

BELL A 297 1523.78 
BITTNER A 302 1676.24 
BRANLEY A 282 1909.99 
CHELOUCHE A 372 1556.33 
CULPEPPER A 317 1652.09 
FEY A 283 1594.33 
FOSTERT A 398 1531.88 
HODGKINS A 292 1615.32 
IVEY A 305 1532.61 
LACO A 311 1480.42 
LOCKHART A 364 1604.34 
MAIN A 280 1884.17 
METCALF A 402 1529.94 
PASADILLA A 277 1604.49 
PENCE A 347 1829.35 
POSEY A 330 1516.01 
SABENE A 417 1571.73 
SALTERS A 240 1719.99 
STEELE A 355 1783.24 
TOY A 322 1680.84 
WRIGHT A 380 1680.84 
YOUNG A 269 1540.98 
BOWMAN B 371 1579.01 
BOYD B 274 1613.38 
BROADWATER B 321 1686.92 
BRYANT B 339 1595.71 
CHICHESTER B 213 1657.98 
CLARK B 253 1668 
DEFORD B 361 1659.11 
FOOTE B 245 1625.93 
FOSTERS B 328 1553.51 
HALE B 282 1590.12 
KROTOW B 260 1691.94 
LANE B 402 1552.16 
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MCDONALD B 192 1894.69 
MONK B 295 1643.82 
OWEN B 262 1689.53 
POWERS B 266 1529.39 
RANDALL B 343 1617.03 
RHOADS B 266 1976.98 
ROGERS B 273 1605.92 
RUST B 297 1769.05 
SHANNON B 330 1676.37 
SMITH B 312 1752.03 
SOONG B 294 1622.87 
STEIN B 208 1648.15 
WHITE B 269 1656.34 

PROC SORT; BY GROUP; 

PROC MEANS; 

VAR DIFFCOST DIFFSKED COSTSKED; 

BY GROUP; 

TITLE 'STATISTICS OF GROUPS A AND B'; 

PROC GLM; 

CLASS GROUP; 

MODEL DIFFCOST DIFFSKED=GROUP; 

MANOVA H=GROUP / PRINTE PRINTH; 

TITLE 'MULTIVARIATE ANOVA OF GROUPS A AND : 
PROC ANOVA; 

CLASSES GROUP; 

MODEL COSTSKED=GROUP; 

TITLE 'COST + SCHED ANOVA FOR GROUPS A AND 


NOTE: GROUP GRADUAL - GROUP A; GROUP ABRUPT - 


! * . 

' / 

B' ; 

GROUP B 
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APPENDIX K: SAS DATA AND CONTROL FILES FOR REPEATED 
MEASURES 


STAFF DECISION REPEATED MEASURES 

OPTIONS LINESIZE=80;DATA;INPUT NAME $ GROUP $ T1 T2 T3 T4 T5 
T6; 

CARDS; 

BELL A 5 5.3 5.5 5.5 5.6 6.2 

BITTNER A 5 6 6 6 7 7 

BRANLEY A 5.96 6.5 7.7 7.7 10.2 10.2 

CHELOUCHE A 4 4 3 3 4 

CULPEPPER A 5 5 7 7 7 4 

FEY A 5 5 4.8 5.6 8 5 

TFOSTER A 5 5 5 5 5 3 

HODGKINS A 5.5 5.5 6 6.5 6.5 6.8 

IVEY A 6 6 6 6 5 4 

LACO A 5.5 5.5 4.9 4.9 4.8 4.8 

LOCKHART A 4.5 4 3.5 3.5 5.5 6 

MAIN A 7 7 7.5 8.5 8.5 8.5 

METCALF A6 6 5.5 2.6 2 2 

PASADILLA A 5 6 6 7 8 8 

PENCE A 6 6 6 5 5 5 

POSEY A 6 6 6 5 4 4 

SABENE A 5 5 1 1 1 5 

SALTERS A 5.5 10.5 10.5 10.5 6 5 

STEELE A 6 6 6 4.5 4.5 4.5 

TOY A55.55556 

WRIGHT A 5 5 6 5 5 6 

YOUNG A 6 6 6.5 6.5 7 7 

BOWMAN B 5 4 6 3 3 5 

BOYD B 5 6 7 8 8 6 

BROADWATER B 5 5 6 6 6 6 

BRYANT B4.546665 

CHICHESTER B 9 10 10 10 10 . 

CLARK B 5.5 7 10 8 8.5 8.5 
DEFORD B 5 4 4 5 5 5 
FOOTE B 6 7 8 9 10 10 
SFOSTER B 5 5 5 5 5 5 
HALE B 5.5 5.5 6.5 6.5 7 7 
KROTOW B 6 6 11 8 8 8 
LANE B 6 5 5 4 2 2 
MCDONALD B 7 12 20 20 . . 

MONK B 5 5 7.5 7.5 7.5 5 
OWEN B 5 6 9 9 9 7 
POWERS 555.33.534 
RANDALL B 5 5 5 5 5 6 
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RHOADS B 6-5 6.5 12.1 12.1 8 9 

ROGERS B 6 6 7 7 7 7 

RUST B 6 6 7 7 7 7 

SHANNON B55665.55 

SMITH B 3.5 3.5 3.5 8.9 8.9 8.9 

SOONG B 5 5 6 6 7 8 

STEIN B 10 10 10 10 10 

WHITE B 7 7 7 7 7 7 

PROC SORT; BY GROUP; 

PROC GLM; 

CLASS GROUP; 

MODEL T1-T6=GROUP/NOUNI; 

REPEATED TIME / SHORT SUMMARY; 

TITLE 'STAFFING LEVEL DECISIONTS'; 

TITLE3 'REPEATED MEASURES FOR GROUP A VERSUS GROUP B'; 


NOTE: GROUP GRADUAL «= GROUP A, GROUP ABRUPT «= GROUP B 
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APPENDIX L: SAS DATA AND CONTROL FILES FOR REPEATED 
MEASURES 


PROJECT COST ESTIMATE DECISION REPEATED MEASURES 

OPTIONS LINESIZE=80;DATA;INPUT NAME $ GROUP $ T1 T2 T3 T4 T5 
T6; 

CARDS; 

BELL A 

BITTNER A 5 6 6 6 7 7 

BRANLEY A 5.96 6.5 7.7 7.7 10.2 10.2 

CHELOUCHE A 4 4 3 3 4 

CULPEPPER A 5 5 7 7 7 4 

FEY A 5 5 4.8 5.6 8 5 

TFOSTER A 5 5 5 5 5 3 

HODGKINS A 5.5 5.5 6 6.5 6.5 6.8 

IVEY A 6 6 6 6 5 4 

LACO A 5.5 5.5 4.9 4.9 4.8 4.8 

LOCKHART A 4.5 4 3.5 3.5 5.5 6 

MAIN A 7 7 7.5 8.5 8.5 8.5 

METCALF A 6 6 5.5 2.6 2 2 

PASADILLA A 5 6 6 7 8 8 

PENCE A 6 6 6 5 5 5 

POSEY A 6 6 6 5 4 4 

SABENE A 5 5 1 1 1 5 

SALTERS A 5.5 10.5 10.5 10.5 6 5 

STEELE A 6 6 6 4.5 4.5 4.5 

TOY A55.55556 

WRIGHT A 5 5 6 5 5 6 

YOUNG A 6 6 6.5 6.5 7 7 

BOWMAN B 5 4 6 3 3 5 

BOYD B 5 6 7 P 8 6 

BROADWATER B 5 5 6 6 6 6 

BRYANT B4.546665 

CHICHESTER B 9 10 10 10 10 . 

CLARK B 5.5 7 10 8 8.5 8.5 
DEFORD B 5 4 4 5 5 5 
FOOTE B 6 7 8 9 10 10 
SFOSTER B 5 5 5 5 5 5 
HALE B 5.5 5.5 6.5 6.5 7 7 
KROTOW B 6 6 11 8 8 8 
LANE B 6 5 5 4 2 2 
MCDONALD B 7 12 20 20 . . 

MONK B 5 5 7.5 7.5 7.5 5 
OWEN B 5 6 9 9 9 7 
POWERS 555.33.534 
RANDALL B 5 5 5 5 5 6 
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RHOADS B 6.5 6.5 12.1 12.1 8 9 

ROGERS B 6 6 7 7 7 7 

RUST B 6 6 7 7 7 7 

SHANNON B55665.55 

SMITH B 3.5 3.5 3.5 8.9 8.9 8.9 

SOONG B 5 5 6 6 7 8 

STEIN B 10 10 10 10 10 

WHITE B 7 7 7 7 7 7 

PROC SORT; BY GROUP; 

PROC GLM; 

CLASS GROUP; 

MODEL T1-T6=GROUP/NOUNI; 

REPEATED TIME / SHORT SUMMARY; 

TITLE 'STAFFING LEVEL DECISIONTS'; 

TITLE3 'REPEATED MEASURES FOR GROUP A VERSUS GROUP B'; 

NOTE: GROUP GRADUAL - GROUP A; GROUP ABRUPT « GROUP B 
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